Психиатрия и системный дизайн

Tech interview that doesn’t suck (Pt. 1)

Как быстро и адекватно проверить навыки инженера и понять, подходит ли кандидат в команду по своим знаниям? Каждая компания эту задачу решает по своему, а я расскажу, как мы решили это в Monite.

Сразу уточним, что мы нанимаем в основном Python backend с познаниями в облаках и контейнерах, поэтому все решения смотрим в этом контексте. Но, скорее всего, для вашего стека технологий найдется аналогичное решение

Сразу откинем вещи, которые мы на технических собеседованиях не делаем (и не будем).

1️⃣🚫 Домашнее написание кода — разработка тестового приложения дома и презентация решения интервьюеру. Маленькое тестовое не имеет смысла (собрать одну красивую функцию или класс) — не говорит о человеке ничего — собрать силы в кулак, погуглить и написать десяток красивых строчек не так сложно. Просить сделать большое тестовое — его надо оплачивать и на него нужно выделять часы-дни для работы. На такое уже не у всех есть время, кандидату проще пойти в другое место, где не попросят писать много кода. А еще за большое тестовое надо платить — а это еще задержки, бумаги инвойсы и операционка. Неоплачиваемое большое тестовое — неэтично. Поэтому писать дома код мы не просим.

2️⃣🚫 Алгоритмические вопросы. Сегодня на работе мало кому надо писать сортировки массивов, обходы графов и прочие классические штуки — это делается готовыми библиотеками. Алгоритмические задачи в большинстве случаев будут нерелевантны рабочим задачам и не покажут навыки кандидата в решении прикладных задач. Исключение — если работа кандидата все же будет связана с алгоритмами напрямую — например, нужно оптимизировать перемещение товаров в графе маршрутов — тогда проверять это надо. С большим количеством алгоритмов мы не работаем — и алгоритмы реализовывать не просим.

3️⃣🚫 Многоступенчатые интервью с разными блоками вопросов. Нужно ценить время, свое и кандидатов. Поэтому мы не делаем 12 ступеней интервью, как это было одно время принято в Яндексе. Нам жалко и своего, и чужого времени — многоступенчатые технические интервью мы не делаем.

4️⃣🚫 Лайв кодинг. У нас он не запрещен, но не рекомендован. Написание сложного кода на экране, на который кто-то смотрит, вызывает у кандидатов стресс и не дает четкой картины. Написание простого кода смысла не имеет. Поэтому лайв кодинг у нас не в ходу.

5️⃣🚫 Обилие базовых вопросов по учебнику для программистов тоже не дает четкой картинки — их можно заучить и повторять, как попугай — при этом в работе над реальными задачами они не помогут. Но некоторые базовые понятия с кандидатом все же стоит проверить. Вокруг вопросов из документции мы интервью не строим.

В сумме получаем, что для нас хороший процесс интервью — короткий, без домашнего программирования, без алгоритмических вопросов, обилия вопросов из учебника и лайв кодинга.

www.tg-me.com/jp/Психиатрия и системный дизайн/com.psychiatry_and_system_design/17

261 viewsedited  Feb 17, 2023 at 07:13

Tech interview that doesn’t suck (Pt. 1)

Как быстро и адекватно проверить навыки инженера и понять, подходит ли кандидат в команду по своим знаниям? Каждая компания эту задачу решает по своему, а я расскажу, как мы решили это в Monite.

Сразу уточним, что мы нанимаем в основном Python backend с познаниями в облаках и контейнерах, поэтому все решения смотрим в этом контексте. Но, скорее всего, для вашего стека технологий найдется аналогичное решение

Сразу откинем вещи, которые мы на технических собеседованиях не делаем (и не будем).

1️⃣🚫 Домашнее написание кода — разработка тестового приложения дома и презентация решения интервьюеру. Маленькое тестовое не имеет смысла (собрать одну красивую функцию или класс) — не говорит о человеке ничего — собрать силы в кулак, погуглить и написать десяток красивых строчек не так сложно. Просить сделать большое тестовое — его надо оплачивать и на него нужно выделять часы-дни для работы. На такое уже не у всех есть время, кандидату проще пойти в другое место, где не попросят писать много кода. А еще за большое тестовое надо платить — а это еще задержки, бумаги инвойсы и операционка. Неоплачиваемое большое тестовое — неэтично. Поэтому писать дома код мы не просим.

2️⃣🚫 Алгоритмические вопросы. Сегодня на работе мало кому надо писать сортировки массивов, обходы графов и прочие классические штуки — это делается готовыми библиотеками. Алгоритмические задачи в большинстве случаев будут нерелевантны рабочим задачам и не покажут навыки кандидата в решении прикладных задач. Исключение — если работа кандидата все же будет связана с алгоритмами напрямую — например, нужно оптимизировать перемещение товаров в графе маршрутов — тогда проверять это надо. С большим количеством алгоритмов мы не работаем — и алгоритмы реализовывать не просим.

3️⃣🚫 Многоступенчатые интервью с разными блоками вопросов. Нужно ценить время, свое и кандидатов. Поэтому мы не делаем 12 ступеней интервью, как это было одно время принято в Яндексе. Нам жалко и своего, и чужого времени — многоступенчатые технические интервью мы не делаем.

4️⃣🚫 Лайв кодинг. У нас он не запрещен, но не рекомендован. Написание сложного кода на экране, на который кто-то смотрит, вызывает у кандидатов стресс и не дает четкой картины. Написание простого кода смысла не имеет. Поэтому лайв кодинг у нас не в ходу.

5️⃣🚫 Обилие базовых вопросов по учебнику для программистов тоже не дает четкой картинки — их можно заучить и повторять, как попугай — при этом в работе над реальными задачами они не помогут. Но некоторые базовые понятия с кандидатом все же стоит проверить. Вокруг вопросов из документции мы интервью не строим.

В сумме получаем, что для нас хороший процесс интервью — короткий, без домашнего программирования, без алгоритмических вопросов, обилия вопросов из учебника и лайв кодинга.

BY Психиатрия и системный дизайн